中台不是万能药!
大家好,我是Tom哥~
今天跟大家聊聊中台,欢迎留言讨论
中台最早是由阿里巴巴推动在国内火起来的,早在2015年,马云带领阿里多位高管拜访芬兰著名的游戏公司Supercell,看到平均一款游戏落地只需要5~7人,被这种高效工作模式触动。
于是,开始在公司内部尝试“大中台,小前台”的架构模式,诞生了阿里巴巴中台战略。
经过15、16两年的时间孕育,在2017年,中台的声音越来越大,很多大厂开始开始搞中台建设,市面上关于中台建设的分享经验也多了起来。
中台极大的释放了企业创新和变革的能力,像阿里的盒马、钉钉都是阿里中台创新的成果。
18年、19年可谓是中台发展元年,很多中小厂、传统企业也参与进来搞中台建设,仿佛一个公司不搞中台,没有中台,都不好意说自己是个互联网技术公司。
潮流引领人,有时也误导人。
中台建设耗时耗力,很多公司的程序员苦不堪言,既要应对正常的业务迭代,还需要抽时间搞中台架构升级。
讲了这么多了,可能有同学要问了,那什么是中台?
中台是企业级能力复用平台。
抽象核心的底层能力,平台化包装,快速赋能前台业务。通过底层的确定性来应对前台业务的不确定性。
可能有同学会问,平台化和中台化有什么区别?
关于这个问题,ThoughtWorks首席咨询师王健老师给出了很好的解释!
中台化是平台化的下一站,是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能,真正为前台而生。
划重点:中台的诞生就是为了更好的服务前台,如果前台业务单一,或业务逻辑并不复杂,其实没必要花那么大的精力搞中台建设,得不偿失。
前台、中台、后台的定位分别是什么?
前台:直接面向用户,讲究的轻量化、灵活多变、快速响应、快速上线 中台:直接为前台提供服务,讲究的核心能力抽象、配置化、稳定、以不变应万变 后台:主要负责企业的核心数据,设计企业安全、审计、合规等法律限制,对稳定性、安全性有较高要求。
如何建设中台?
中台建设没有固定模板,不同公司的设计方案也是千差万别。把控一点,能快速响应前台业务需求。一般企业会设计类似流程引擎这种支持通过界面拖拽
的方式,来配置不同的业务流程。
平台提供了若干基础组件功能,定义好每个组件的规范、输入、输出,不同业务流程通过选择不同模块来编排自己的业务流程,从而快速满足业务需求。
对变化频繁的接口,我们会设计SPI接口
,支持业务方自定义代码实现
,动态加载
到我们的平台,然后由平台统一调度请求。
当然不同人开发的接口性能也不太一样,发布前除了要做性能压测外,我们还会提供一些基础服务治理功能,比如:接口超时处理
、重试机制
、流量控制
、降级
、熔断
等稳定性方案,保障系统的高可用。
中台建设可能遇到的问题?
任何事情都不会是一帆风顺,搭建中台也会遇到很多问题,遇到最多的就是,这个功能到底是由中台来做,还是由业务研发来做?
这个很容易导致中台部门和业务部门之间的扯皮,严重影响业务的落地速度。这就需要一个强有力、善于跨部门沟通的中台负责人,对该业务领域有丰富的业务经验,能从技术视角预测未来的业务走势,从而对功能归属做出定位判断,再结合强有力的沟通,推动该事情落地。
当然,这个结论是否正确,还需要漫长的时间验证,长时间的正确决策会慢慢巩固你的中台权威,形成正向循环。
中台建设是一个自上而下的过程,大家是一个集体,一荣俱荣,千万不能有小帮派思想,一盘散沙很难成事,这个需要总负责人在公司有很高的话语权。甚至把中台建设设定成公司的战略,跟业务有着对等的地位。
当然也不是所有的公司都要搞中台建设,如果公司的业务线不超过三条,或者各业务线的通用模块并不多,最好不要搞中台建设。中台建设是业务发展到一定阶段的自然产物,当投入和产出严重失衡时,我们便可以从中台视角,通过技术手段对其优化,降低公司成本。
中台小故事
当然,我们也要注意一个点,中台的产品要如何规划,有些小公司想搞中台建设,可是产品人员不足。于是中台的产品经理便由前台业务产品经理来兼任。
前台产品经理一般直面客户,要求快速响应客户需求,这些需求通常都是多变性
,很多甚至带有业务探索性质
,对创新性
要求很高。
而中台产品经理更多是为前台技术团队提供服务,讲究抽象能力
、共享
、降低企业管理成本
,将一些稳定的逻辑沉淀到中台,节奏肯定很慢。
如果将两者放到一个人身上,就好比要求一个人既要走的很快,甚至要跑起来,又要走得优雅,走出美的感觉,有种自相矛盾。
所以,我们做人员组织架构安排时,还是要慎重些,该投入的成本一定要舍得。既想要中台的高产能力,又想节省成本,不舍得应有的技术投入,这不是天方夜谭,最后只会竹篮打水一场空。
中台更多适合在一些高确定性
、高通用性
的场景下孵化建设,这样更利于发挥其最大价值。
摆正心态
由于中台的自身属性决定,收编前台核心逻辑,有点江湖大哥
的味道,中台的开发同学一定要摆正自己的工作态度,千万不要以平台建设稳定、较长研发排期等理由搪塞前台业务同学,很容易遭到业务研发的不满和投诉,毕竟客户就是上帝。
另外,本着简单就是最优的原则
,不是所有的业务都要接入中台,一些简单的功能可能会被中台的复杂规则带偏节奏,人为的将其复杂化,从而加长开发工期。我们的目标是尽快落地,而不是接入中台。一定要保持清醒的头脑,不要盲从。
中台不是万能药
由于中台的高复用能力,很多人会有种错觉,感觉中台无所不能,全是优点。
殊不知,任何系统都不天生完美的,一个成熟的中台也需要日积月累的打磨、优化,这些都需要资源。
很多创新业务,如果能直接对接进中台还好一点,如果涉及中台技术改造,那可能就要走排期。由于创新业务失败的风险极高,竞争中台资源排期时,不如一些较成熟的业务有优势。
较慢的项目排期,又无法保证创新业务的快速试错,恶性循环。如果操作不当,中台甚至可能会扼杀一些创新业务的崛起,使公司错失一些优秀产品。
创新分为颠覆式创新
、组合式创新
。中台产品一定要灵活,深入思考如何服务好业务研发,服务好产品创新。快速接入、延缓接入、早期甚至由业务团队自建,关键一个字要 “快”。
谈谈未来
最近几年,中台的热度开始下降,去年圈内有关中台的一件事传的非常火爆,阿里CE0张勇在阿里内网发布文章,表示目前阿里的中台并不满意,他直言道,现在阿里的业务发展太慢,要把中台变薄,变得敏捷和快速。
那是不是中台就要凉了
?个人觉的应该不会。
中台的位置偏底层,投入成本巨大,很难像业务直接看到收益,老板们有焦虑心态也是可以理解。但中台的价值也是不容小觑,当然中台与前台的边界博弈也一直存在。
如何做到两者的平衡是很多公司在探索的事情,正如历史所言,“天下大事分久必合,合久必分”,中台也是一样,不断的优化。
未来,中台会越来越薄
,越来越碎片化
。甚至可能换个名称,不再叫“中台”,但是他的价值却始终是我们要追寻保留的。
推荐阅读
JAVA那点破事!并发、IO模型、集合、线程池、死锁、非阻塞、AQS....